1. Field of the Invention
This invention relates to data processing systems having virtual storage support, and real storage managers for managing real storage for use within the virtual storage support of the data processing system. More particularly, this invention describes a mechanism for having the system's real storage manager provide a data copy service.
2. Background Art
When programs which execute on virtual storage systems such as International Business Machine's (IBM's) System/390 need to copy data from one location in byte addressable storage (the source) to another location in byte addressable storage (the target), they reference the source and target data by their addresses which are subsequently transformed into "from" and "to" operands by machine architected instructions like move character (MVC) and move character long (MVCL).
In accordance with ordinary use, the word "target" in the present description generally pertains to a storage location to which data is written, while "source" pertains to a storage location which contains data to be written to a destination such as a target. In some areas of this description, these storage locations are also referred to as "target frames" and "source frames." The word "frame" is generally used here, as it is used in the literature, to refer to a fixed-size portion of storage in which data is stored.
Additionally, the terms "target data" and "source data" refer to the data written to the target (or target frame) and the data contained in the source (or source frame), respectively. In some cases, "target data" is referred to as a "target page" and "source data" is referred to as a "source page." The word "page," in one context, refers to a fixed-length block of data that has a virtual address and is transferred as a unit between storage. In another context, the terms "page" and "page frame" are used interchangeably to refer to a storage location having the size of a page.
When such a program executes in the environment of an operating system such as IBM's Multiple Virtual Storage-Enterprise Systems Architecture (MVS/ESA), references to byte addressable storage are resolved by a processor storage manager such as MVS/ESA's Real Storage Manager (RSM). Processor storage includes central storage, (which contains real storage) and expanded storage and is managed by RSM. RSM performs many tasks when allocating and managing the processor storage for the active units-of-work (e.g. programs) in the system, and one of those tasks is to ensure that data needed by the currently executing units-of-work reside in central storage. When a unit-of-work is copying data with instructions like the MVCL, the hardware and/or microcode support for the MVCL require that the operands reside in central storage. If the operands do not reside in central storage, page faults occur and this triggers the intervention by the RSM. It is the RSM's responsibility to intercept requests for data that is not resident in central storage and to ensure that:
1. Central storage is assigned to the source and target (i.e., pages in the central storage are reserved for the source and target), PA1 2. The most up-to-date version of the source data resides in the central storage pages that are reserved for the source. PA1 This can entail the need for Paging input/output (I/O) to read the source data from the auxiliary storage devices that contain the paging data. Or, it may entail the need to move the source data from expanded storage to central storage. PA1 For either action, the RSM adjusts the storage reference pattern to indicate that the storage assigned to the source and target is the most recently referenced storage and is therefore the last storage to get reclaimed and reassigned to future demands for central storage. PA1 1. It exploits the RSM's knowledge of duplicate copies of data and reduces the need for data movement in the copy process. PA1 In addition to avoiding multiple copies in central storage (unlike MVCL), RSMCOPY is also able to determine if duplicate copies of a page already exist, and selects one of them as the target copy of the page. PA1 2. It minimizes the demand on processor storage. PA1 RSMCOPY is able to determine if sufficient expanded storage exists to put the target data there, rather than make a duplicate copy in central storage. For situations where RSMCOPY must make a duplicate copy of the data in central storage, RSMCOPY is able to write (off-load) that copy of the data to auxiliary storage immediately. PA1 3. It avoids upsetting storage reference patterns in the system. PA1 RSMCOPY ensures that the storage reference patterns of the source data reflect the "reference status" prior to the copy request. Since RSMCOPY is controlling the copying of data, RSMCOPY is able to free up resources as soon as copying of each page is done. RSMCOPY is also able to make copied data look "older" in storage than data that is in processor storage when the copy request is issued. PA1 4. It provides the caller (the requestor who invoked the copy service) with the choice of either a nondestructive or a destructive copy of the source data. PA1 RSMCOPY guarantees a nondestructive process for the source data. At the completion of the copy request, the source data resides on an equivalent or faster access storage than when the copy request was issued. In addition the caller can override the nondestructive copy by explicitly requesting that the RSMCOPY use the resources currently assigned to the source and reassign assign them to the target (a destructive copy).
The inefficiencies of the MVCL logic are not that noticeable when copying relatively small amounts of data. But when massive amounts of data (measured in megabytes) are copied, then the effect of the inefficiencies is noticeable. The supervisor call (SVC) Dump service of the IBM operating system Multiple Virtual Storage (MVS) is an example of a function that copies a large amount of data to its own data spaces.
This MVCL technique impacts the storage resources of the system, resulting in system performance degradation. It can result in page faults on both the source and target pages and increases the demand for central storage (real storage) to hold the copied pages. As a general rule in migrating data from central storage and in reassigning pages of central storage to meet the demands of currently active work (a process called page stealing), the RSM supports the least recently used (LRU) concept as the most appropriate predictor of storage references. Therefore, in responding to an MVCL instruction for large amounts of data, the RSM may be forced (or "migrate" off) the pages of data located in central storage, which are assigned to the units-of-work which were active at the time of the SVC Dump request, and then assign those pages to target data from the MVCL. But the replaced or migrated pages are likely to be referenced immediately once the copying process is complete, causing yet more paging activity. This can significantly affect the performance of the entire system, including units-of-work which are not associated with the MVCL issuer, since pages may be stolen from those units-of-work to accommodate the data copying. The effects may be visible long after the MVCL form of copy is completed.
The SVC Dump service normally uses MVCL logic to create its own copy of dump data. This method causes two copies of the dump data, the source and the target, to reside in central storage at the time the copy is made. This greatly increases the demand on central storage when a dump was being taken. In storage constrained environments this can severely impact system processing. It also disrupts the normal storage reference patterns, since the data referenced by SVC Dump (both the source and target data) looks like the most recently referenced data in the system. Units of work that are completely independent of and not involved with the unit-of-work that requested the SVC Dump, are impacted since their data may have been migrated to slower access storage. The target data look like the most recently referenced data, and are not likely to be accessed when the copying is completed. The target data instead are referenced after some time by the "I/O to the Dump Dataset" phase of SVC Dump.
The preferred effect on central storage and storage reference patterns as a result of copying data for inclusion in a dump, is to have the storage reference pattern of the source be unchanged by the copy action, to have the minimally necessary growth in central storage consumption, and to have the central storage pages which are assigned to the target data be tagged as the primary candidates for the next page stealing process.
Therefore, it is an object of this invention to provide a fast copy mechanism that avoids the overhead of page fault processing when the source and/or the target are not resident in central storage.
It is a further object of this invention to provide a fast copy mechanism that minimizes the consumption of central storage resources by the target data with the additional ability for the central storage pages that are assigned to the target to become the primary candidates for migration to slower access storage.
It is a further object of this invention to provide a fast copy mechanism in which the storage reference patterns of the source data remain unchanged by the copy process.